One of the reasons the World Wide Web (or Web) is so popular is the ability of users to publish and interact with rich content. Examples of rich content include Web sites with both foreground and background images, multiple colors, interactive controls, fonts, audio clips, code modules, and animation. Users generally interact with rich content using Web browsers. Web browsers display rich content from Web sites to the user and permit the user to interact with rich content using input devices such as a keyboard or a mouse. Many software applications generate professional looking rich content that may be displayed on Web sites. These applications enable a user to create rich content including images, fonts, sounds, animation, and user-interactive controls. As more users discover the rich content available through various networks, such as the Internet, the stability of Web browsers is increasingly more important.
Web browsers generally display “standard” rich content: rich content containing those features defined according to some standard. HTML (hypertext markup language), XHTML (extensible hypertext markup language), and XML (extensible markup language) are examples of rich content formats that have been “standardized” by the World Wide Web Consortium (the W3C), a widely recognized standardization body for developing interoperable technologies for information exchange, commerce, and communication on the Web.
Before they become standards according to the W3C, or some other standardization body, proprietary or specialized features developed within the foregoing (and other) formats are deployed on Web sites. Some of these new features may never be standardized. For these cases, most Web browsers have been developed to accept plug-in modules. In general, plug-in modules are software extensions to an application, specifically, in this case, a Web browser such as Microsoft's Internet Explorer®. A user will typically install a plug-in module into a specific directory location associated with a Web browser. This will typically be a known location that the Web browser searches when starting up. If the plug-in module is properly located, the Web browser will interact with the plug-in module to extend or enhance the Web browser's abilities, including displaying nonstandard, proprietary features stored in a Web file.
Among many other items, existing Web browsers support plug-in modules that provide rich content such as ActiveX controls, browser helper objects, toolbar extensions, and the like. The above-described rich content may be provided by individuals or organizations with the desire to add functionality to an existing Web browser (i.e., third parties). Combining these features—Web browsers adapted to function as display modules having plug-in extensibility—creates an extremely adaptable and powerful display and extensibility mechanism. Unfortunately, plug-in modules, if designed incorrectly, may cause a Web browser to “crash” or fail. As known to those skilled in the art and others, failures are frustrating to users and may result in the loss of information. Typically, a failure occurs when a program performs an operation that is not permitted by an operating system.
A substantial portion, if not almost all, of the failures in existing Web browsers are caused by errors in plug-in modules. To the user, the cause of the failure is unknown. Some users mistakenly believe that the failure is caused by an error in the Web browser and continue to use plug-in modules created by third parties, resulting in continued instability. Obviously, the usability of the Web browser is reduced when the user does not know the cause of a failure and is unable to prevent future failures. Existing Web browsers do not identify the cause of a failure or assist users in preventing future failures. Instead, Web browser providers receive reports from users who experience failures and from these reports identify the cause of the failure. If a plug-in module caused the failure, the Web browser provider may either provide an update that disables the plug-in module or request an update from the third party that created the plug-in module.
As mentioned above, the current Web browser failure prevention paradigm is a reactionary system, i.e., the Web browser is updated to prevent failures only after failures are reported. Furthermore, the Web browser update cycle is an extremely costly process for the Web browser provider, and ultimately for consumers of the Web browser.
In light of the above-identified problems, it would be beneficial to computer users, both in terms of convenience and in terms of cost-effectiveness, to have a Web browser that identifies plug-in modules that cause failures. Further, it would be beneficial to computer users to have a Web browser that allows users to disable or update plug-in modules that cause failures. Embodiments are directed to providing such a Web browser.